The OT bus stop uses a mechanism named Data Type Scope to indicate the level of detail that an operation uses to report data to the bus stop.
To understand the use of the data type scope, it is important to understand how an operation works. An operation is a unit of work that can span multiple machines producing one or more products but it may also be a single machine performing a single task on one or more items.
The examples below show how operations work and how they report this is important to the bus stop. It’s not always a good idea to report per work order, sometimes you want to report per product or per equipment. This is where the data type scope comes in. The data type scope is a set of keys that is used to split a work order into smaller work orders depending on how the operation is triggered and reporting. The keys are also used to find a queued (buffered) work order in the OT bus stop.
So, why are Operation and Order ID always part of the data type scope? Well, The (B2MML) OperationsSchedule (work order) contains an OperationsRequest which stands for the order ID. The OperationsRequest contains one or more SegmentRequirements which stand for process segments (operations). In other words, the order ID and operation are mandatory data type scope keys because the OT bus stop will split the OperationsSchedule by order and operation anyhow because the bus stops are operations oriented.
A few things to remember:
If the OT bus stop receives a channel message that is not able to find a queued work order, a new work order will be created using the information provided in the channel message.
If a channel message matches with 1 or more work orders, all matched work orders will be updated.
If a channel message requires a specific tag value as data type scope key, then these tags should be marked as mandatory. Failing to do so may end up in multiple work orders being updated because the remaining scope keys might match multiple work orders.
Make sure that there is only one instance of the name 'OrderId', 'LotId', 'SerialNumber' or 'EquipmentId' in your message definitions otherwise the wrong value may be used in the Data Type Scope.
The OT bus stop currently supports the following data type scopes:
Order ID + Operation
Order ID + Operation + Batch ID
Order ID + Operation + Serial Number
Order ID + Operation + Equipment ID
Order ID + Operation + Batch ID + Serial Number
Order ID + Operation + Batch ID + Equipment ID
Order ID + Operation + Serial Number + Equipment ID
Order ID + Operation + Batch ID + Serial Number + Equipment ID
Order ID = Work order ID
Let’s look at a few examples:
An operation contains a machine pressing pills. The individual pills don’t have a serial number but they belong to a batch. This machine is triggered as soon as it receives a work order and reports the status per batch.
Performing automated tests on single items where the procedure is started by scanning a serial number. This machine is triggered by a serial number and reports the test results back per serial number.
A production cell contains 3 machines bending pipes that are sub-assemblies of an exhaust system. The sub-assemblies don’t have a serial number, and the machines only report a summary containing the machine ID at the end of the production run.
So reviewing the examples and knowing what data type scopes that are available:
Example 1 would use ‘Order ID + Operation + Batch ID’
Example 2 would use ‘Order ID + Operation + Serial Number’
Example 3 would use ‘Order ID + Operation + Equipment ID’
Can we improve this topic?